1. Field of the Invention
The present invention relates to network transmissions and, more particularly, to a method and apparatus for enhancing feedback information available in a cumulative acknowledgment transmission protocol, to allow network parameters such as the round-trip time to be measured during retransmission periods, and to accelerate loss recovery.
2. Description of the Related Art
Data communication networks may include various computers, servers, nodes, routers, switches, hubs, proxies, and other network devices coupled to and configured to pass data to one another. These devices will be referred to herein as “network devices.” Data is communicated through the data communication network by passing data packets (or data cells or segments) between the network devices by utilizing one or more communication links between the devices. A particular packet may be handled by multiple network devices and cross multiple communication links as it travels between its source and its destination over the network.
The various network devices on the communications network communicate with each other using predefined sets of rules, referred to herein as protocols. The protocols will typically specify various aspects of what the data packets should look like and how they should be handled by the network devices. One aspect of a protocol may be to define whether packets are to be acknowledged by the receiving network device. Acknowledgements enable the sending network device to receive feedback as to how the network is handling the packets and whether the packets are reaching their intended destination.
One commonly used protocol, Transport Control Protocol (TCP), uses positive acknowledgements to allow the sending network device to assess network conditions and to adjust transmission parameters accordingly. The use of TCP acknowledgements and adjustment of transmission parameters are discussed in greater detail in IETF RFC 2581, the content of which is hereby incorporated by reference. TCP utilizes cumulative acknowledgements that indicate to the sending network device that the receiving device has received all data up to a particular point.
One of the parameters measured in TCP is the round-trip time (RTT). The round-trip time is the difference between the time a segment with a particular sequence number is sent, and the time an acknowledgment covering that sequence number is received. The round-trip time may be used in TCP to adjust transmission parameters in the sending network device to prevent the sending network device from transmitting too much data onto the network. Examples of transmission parameters derived from the round-trip time include, for example, the smoothed RTT, the smoothed RTT mean deviation, and the retransmission timeout. Use of the round-trip time to adjust transmission parameters is discussed in greater detail in IETF RFC 2988, the content of which is hereby incorporated by reference.
Measurement of the round-trip time may be particularly important in a network that has varying time delays over links connecting network nodes, for example in a wireless network where the link between the end user and the base station may be transitory or where environmental or other conditions may affect the available bandwidth between the sender and the base station. In the event of rapidly deteriorating network conditions, it is desirable to measure the round-trip time often, possibly on every packet, to continually assess network conditions.
If an acknowledgment is not received within a certain period of time, as measured by a retransmission timer, the sending network device will assume that the packet was lost in the network and will retransmit the packet. Numerous other conditions may also cause a retransmission, for example, where a packet is damaged or where acknowledgments from other packets indicate that a particular packet was likely to have been lost.
Unfortunately, the sending network device cannot discern between an acknowledgment associated with the originally transmitted packet or the retransmitted packet. This results in a problem known as retransmission ambiguity. Specifically, when a TCP sender receives an acknowledgement for a packet that has been transmitted more than once, the sender has no way of knowing which of the multiple transmissions is being acknowledged. If, on the other hand, the first transmission was indeed lost and the sender receives an acknowledgement for the retransmitted packet it can only guess, sometimes incorrectly, that the packet following the retransmitted one was lost as well. The effects of retransmission ambiguities on TCP's Fast Recovery Algorithm are discussed in greater detail in IETF RFC 2582, the content of which is hereby incorporated by reference.
One way to avoid retransmission ambiguity is to use a time stamp to uniquely identify packets with acknowledgments, see IETF RFC 1323, the content of which is hereby incorporated by reference. This solution, unfortunately, is not optimal since it has a relatively high bandwidth overhead, as the timestamp typically adds 12 bytes to the 40-byte TCP/IP header of a TCP segment. This overhead can be quite significant in low bandwidth or asymmetric channel environments (e.g. wireless access networks). Additionally, some clients do not support timestamps (e.g. Windows NT) and it is disabled by default in other versions of Windows. Accordingly, implementation is difficult since it requires modification to end user software.
Another solution, originally proposed by Karn and Partridge and described in IETF RFC 2988, is to not use the acknowledgements of packets that have been transmitted more than one time when making round-trip time measurements. While this removes the ambiguity caused by retransmissions, it excludes valuable opportunities for measuring the round-trip time. This may be particularly important in the event that the delay is caused by rapidly changing network conditions. In this situation, the acknowledgement for the retransmitted packet may be the first positive indication that the sender would have had of the change in network conditions.